home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 1 (Walnut Creek)
/
Aminet - June 1993 [Walnut Creek].iso
/
usenet
/
sources
/
volume90
/
util
/
kill2090
/
part01
/
resetcode.txt
< prev
next >
Wrap
Text File
|
1990-10-14
|
7KB
|
195 lines
Group: comp.sys.amiga.tech, Item 2342 (Current Item Range #2253 - #2365)
Subject: ColdReboot() - The Never Ending Story?
From: rbabel@babylon.UUCP (Ralph Babel)
Date: 15 Aug 90 04:55:43 GMT
Brief history:
The original "ColdReboot()" (new Amiga Hardware Reference
Manual, page 219) didn't work on some (IMHO) broken A2000s
(Kickstart ROM doesn't reappear at location 0 after RESET).
The current version (AmigaMail March/April 1990) jumps
directly into Kickstart and therefore doesn't co-operate
with boot-ROMs (not to be confused with Autoboot driver
ROMs) that show up at location 0 after a software RESET
(e.g. it leaves the A1000's WCS write-enabled and does not
work with GVP's '030 boot-ROMs - dunno about A2620/A2630).
Presumably this bug also prevents the current versions of
"MMUKick" and "SetCPU ROMBOOT" from working with boot-ROMs.
So what about the following solution?
------------------------ cut here ------------------------
* This is Beer-Ware. If you find this program useful, you
* are morally obliged to buy me a drink at the next Amiga
* show or devcon. :-)
csect "text",0,1,0,4
include "exec/types.i"
include "exec/execbase.i"
AbsExecBase equ 4
_LVOSupervisor equ -30
_LVOColdReboot equ -726
LIBRARY_VERSION_2_0 equ 36
_ColdReboot
movea.l AbsExecBase.w,a6
cmp.w #LIBRARY_VERSION_2_0,LIB_VERSION(a6)
blt.b 1$
jmp _LVOColdReboot(a6)
1$ lea 2$(pc),a5
jsr _LVOSupervisor(a6)
*
* in case our boot-ROM doesn't show up at location 0 ...
*
* romsize equ $00ffffec
* romend equ $01000000
*
* $000002: bra.b $000008
* $000004: AbsExecBase
* $000008: lea romend+4,a0
* $00000e: suba.l romsize-(romend+4)(a0),a0
* $000012: movea.l (a0),a0
* $000014: subq.l #2,a0
* $000016: jmp (a0)
*
2$ lea (2).w,a0
movea.l a0,a1
move.w #$6004,(a1)+
addq.l #4,a1
move.l #$41f90100,(a1)+
move.l #$000491e8,(a1)+
move.l #$ffe82050,(a1)+
move.l #$55884ed0,(a1)
btst.b #AFB_68020,AttnFlags+1(a6)
beq.b 3$
movec.l cacr,d0
bset.l #3,d0
movec.l d0,cacr
3$ cnop 0,4
reset
jmp (a0)
end
------------------------ cut here ------------------------
Restrictions: Does not support '040 under pre-2.0; assumes
all boot-ROMs have a JMP-$absolute at location 2; and the
usual MMU restriction (turn off MMU before rebooting). Maybe
Dave has a good idea on how to turn off the MMU without
pulling the rug from under your own feet (SetCPU ROMBOOT)?
Comments appreciated,
Ralph Babel
....!cbmvax!cbmehq!babylon!rbabel
Group: comp.sys.amiga.tech, Item 2349 (Current Item Range #2253 - #2365)
Subject: Re: ColdReboot() - The Never Ending Story?
From: daveh@cbmvax.commodore.com (Dave Haynie), Commodore, West Chester, PA
Date: 16 Aug 90 16:32:13 GMT
In article <03021.AA03021@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes
:
>Brief history:
>The current version (AmigaMail March/April 1990) jumps
>directly into Kickstart and therefore doesn't co-operate
>with boot-ROMs (not to be confused with Autoboot driver
>ROMs) that show up at location 0 after a software RESET
>(e.g. it leaves the A1000's WCS write-enabled and does not
>work with GVP's '030 boot-ROMs - dunno about A2620/A2630).
>Presumably this bug also prevents the current versions of
>"MMUKick" and "SetCPU ROMBOOT" from working with boot-ROMs.
I'm not sure what the GVP boot ROMs actually do, but with the A2620 and
A2630, these ROMs are gone forever by the time you're into AmigaOS the
first time after a full system reset (eg, powerup, keyboard, or any other
condition that yanks both RST* and HLT*). Basically, after a full system
reset, the A26x0 ROMs are mapped at 0 and a magic A26x0 control register
is mapped into the $00e8xxxx space normally used for AUTOCONFIG units.
This magic control register is similar to, but not identical to, a normal
AUTOCONFIG unit, and Exec would certainly choke on it. The control
register is actually at $00e80040, and it can be written to repeatedly
until the configuration bit in the register is set. At that point, this
magic control register goes away, normally until the next full-system
reset. It is replaced at $00e8xxxx by the configuration unit for the
A26x0 on-board memory, which is a true AUTOCONFIG unit understood by
expansion.library and all. Any CPU-generated RESET will bring you back to
this state, but not back to the initial state where the magic register is
accessible or A26x0 ROMs are visible.
>Maybe Dave has a good idea on how to turn off the MMU without
>pulling the rug from under your own feet (SetCPU ROMBOOT)?
If the MMU is on, make sure you're done running any OS code before you turn
it off. That's about all you can do. For SetCPU ROMBOOT, I do just this.
If you're running under 2.0, SetCPU setfunctions its own reset routine, which
will [a] not live in emulated ROM at the time of reset, and [b] turn off the
MMU just prior to resetting.
>Ralph Babel
--
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
{uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy
Get that coffee outta my face, put a Margarita in its place!
Group: comp.sys.amiga.tech, Item 2353 (Current Item Range #2253 - #2365)
Subject: Re: ColdReboot() - The Never Ending Story?
From: valentin@cbmvax.commodore.com (Valentin Pepelea), Commodore, West Chester,
Date: 16 Aug 90 20:43:59 GMT
In article <03021.AA03021@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel)
writes:
>
> The original "ColdReboot()" (new Amiga Hardware Reference Manual, page 219)
> didn't work on some (IMHO) broken A2000s (Kickstart ROM doesn't reappear at
> location 0 after RESET).
>
> (e.g. it leaves the A1000's WCS write-enabled and does not work with GVP's
> '030 boot-ROMs - dunno about A2620/A2630). Presumably this bug also prevents
> the current versions of "MMUKick" and "SetCPU ROMBOOT" from working with
> boot-ROMs.
I'm not sure what you are talking about here. I wrote MMUkick with the
specific purpose to allow GVP accelerator owners to boot OS 2.0 kickfiles.
I even had to help GVP find out why initially, MMUkick would not work. To
fix that they had to replace their PALs with new ones which properly
propagate the *RESET signal from the CPU to external devices, and did not
inhibit the cache for CPU fetches from chip memory.
> So what about the following solution?
Self modifying code is dangerous to your health. In this case, remember to
Disable() all interrupts before entering the critical region.
Valentin
--
The Goddess of democracy? "The tyrants Name: Valentin Pepelea
may distroy a statue, but they cannot Phone: (215) 431-9327
kill a god." UseNet: cbmvax!valentin@uunet.uu.net
- Ancient Chinese Proverb Claimer: I not Commodore spokesman be